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Sir: 


I, Eran Aloni, hereby declare and state: 

I am a joint inventor of the invention entitled "System And Method For Notification Of 
An Event", disclosed and claimed in U.S. Application No. 09/475,147 filed on December 30, 
1999 (hereinafter the '"147 application"), which is a Continuation-in-Part Application of U.S. 
Provisional Application No. 60/152,362 filed on September 7, 1999. 

Prior to July 20, 1999, in Israel (a WTO member country), I, along with my co-inventor, 
had invented the invention as described and claimed in the above-identified applications, and 
pursued the present invention in the ordinary course of business, including preparing the above- 
identified patent applications, until the filing of the above-identified applications, as evidenced 
by the following: 


DECLARATION UNDER 37 C.F.R. § 1.131 
U.S. Application No. 09/475,147 
Attorney Docket No. Q58584 

Prior to July 20, 1999, 1 received an e-mail 1 dated June 21, 1999 from a Mr. Eli Jacobi, at 
which time we were both employed by Comverse, Ltd. (then Comverse Network Systems, Ltd.), 
the assignee of the '147 application by virtue of an assignment recorded in the U.S. Patent and 
Trademark Office on April 11, 2000 at Reel 010692, Frame 0766. The e-mail included an 
attached PowerPoint file 1 identifying myself as an inventor of "A Method To Perform Enhanced 
Notification In A Unified Messaging Environment", on which the '147 application was based 
{see page 8 of the PowerPoint file). The e-mail also included an attached inventor questionnaire 2 
entitled "Preparatory Questions To The Inventors" to be completed by the inventors, including 
myself. A purpose of the e-mail dated June 21, 1999 was to schedule a meeting (on June 27, 
1999 at 9:00 a.m.) to give a general review of the subject matter of the inventions set forth in the 
aforementioned PowerPoint file. 

Prior to July 20, 1999, 1 replied to Mr. Jacobi 's e-mail dated June 21, 1999 by sending an 
e-mail- on July 6, 1999. I attached the aforementioned inventor questionnaire, which I 
completed at least by July 6, 1999, to this e-mail.- The inventor questionnaire completed by me 
includes, for example, a brief description of the invention. 


1 A copy of this e-mail is attached hereto as Exhibit A. 

- A copy of this PowerPoint file is attached hereto as Exhibit B. 

- A copy of this inventor questionnaire is attached hereto as Exhibit C. 

- A copy of this e-mail is attached hereto as Exhibit D. 

- A copy of this completed inventor questionnaire is attached hereto as Exhibit E. 
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DECLARATION UNDER 37 C.F.R. § 1.131 
U.S. Application No. 09/475,147 
Attorney Docket No. Q58584 

Prior to July 20, 1999, a document entitled "Notification HTTP Protocol", which relates 
to aspects of the invention, was initiated (version 0) at least by June 14, 1999.- Prior to July 20, 
1999, 1 contributed to this document by preparing an updated version (version 1) at least by July 
14, 1999. I continued to make further more minor revisions (versions 1.0.1, 1.0.2, 1.0.3 and 
1.0.4) to this document on July 19, July 20, July 26 and July 27, respectively. 

In view of the above, and the attached copies of the corresponding documentation, I 
respectfully submit that I had completed and reduced to practice the system and method for 
notification of an event as described and claimed in the £ 147 application prior to July 20, 1999. 

I declare further that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code, and that such willful false statements may jeopardize the validity of the application or any 
patent issuing thereon. 




Eran Aloni 


- A copy of this document is attached hereto as Exhibit F. 
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From: Jacobi, Eli [Eli_Jacobi1 1 1 @ icomverse.com] 

Sent: Monday, June 21 , 1 999 5:31 AM 

- To: Neishlos, Ruth; Braverman Arie; Gonen, Dror; Keini, Gil; Grosu, Yair; Gluska, Eya!; Khachaturov, Vassilii; 

Weingarten, Jerry; Neystadt, John; Kadish, Shoshana; Cattan, Ariel; Aloni, Eran; Zimerman, Heny; Gadt, Amir 

Cc: Wietchner Meir; Gerlitz, Sachi; Kerbis, Michael; Rothschild, Menashe; Ron, Tamir; Gilon Arik; Gronner Mosh; Zohar 
Avi; Steinmetz Daphna; Erev, Ah; Levy, Arie; Wolfgor Irit; Inon, Gad; Levy Jimmy; Leven, Daniel; Eshel, Hanoch; 
Beery, Gidi; Shalev, Daniel 

Subject: Patent activity session - the first step 
Dear inventor, 

You have been identified by your manager as the inventor of the invention indicated below. (See PPT fie). 

The subject of inventions and the creation of a patent portfolio has been given a very high priority by CNS top management. 

Please plan on joining a meeting on Sunday, June 27th at 9:00AM in Rm. 498 in Efrat II. 

The agenda is to give a general review of the subject of inventions and intellectual property in general. 

We will then start working on the ideas detailed below. An external consultant will be at the meeting, helping us in the process. 

The meeting is scheduled for 3 hours. However, based on people time constraints, we may decide after the introduction and the 
presentation of the first invention to rearrange the meeting in smaller groups, so some of the people will be invited for the latter 
part of the session. 

For the session to be productive and useful, I would like to ask you to do some preparation: 

1) Please answer the attached questionnaire as thoroughly as you can. 

2) Please prepare 1 -2 foils (prepare 20 copies, and email me the foils in PowerPoint before the meetng so we can project them) - 
detail in the foil the idea of the invention, (few words to expand on the title mentioned below.) 

Questionnaire: 

«Comverse- questionnaire to inventors.doc» 


List of inventions/managers/inventors 
«patent Review.ppt» 


Thanks in advance to everyone, 
-- Eli 

Eli Jacobi 

Director of Technology 

Comverse Network Systems 

Tel. +972-3-645-4176 

Fax. +972-3-645-4088 

Email: Eli_Jacobi@icomverse.com 
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PREPARATORY QUESTIONS TO THE INVENTOR(S) 

The INVENTORS are defined as the individuals that provided a SOLUTION 
TO A specific PROBLEM. It is preferable that the leading inventor will 
answer the questions. 

[l] An invention is a solution to a problem. Describe the problem. 

[2] Describe briefly the invention. The explanations can be given 
on the whiteboard or assisted by pre-prepared schemes. 

[3] What is the impact of the invention on the project/ product/ 
technology. 

Can you define the invention as VITAL [ ] IMPORTANT [ ] HELPFUL [ ] ? 

fa] Was the invention practiced before in Comverse? Elsewhere? Have 
you 

seen this solution in writing in the professional media? in a 

PATENT? 

a similar solution? 

[5] Have you (or anyone else) seen this solution practiced in a product? 
A similar solution? A product by a competitor? 

[6] do you have regular access to trade magazines, technical articles? 
Are you visiting trade shows, or is information (related to your 

FIELD OF 

Interest) leaked to you from such shows? 
[7] Are you doing patent searches on new technologies practiced by 

YOU? 

If yes, have you found any patents relevant to the invention? 


THE PRESENTATION OF EACH INVENTION WILL TAKE NO MORE 
THEN 15 MINUTES, FOLLOWED BY A DISCUSSION AND FOLLOW-UP 
QUESTIONS. 


From: Aloni, Eran [IMCEAEX-_0=BOSTECH_OU=COMMNET„CN=RECIPIENTS_CN=EALONI@comverse.com] 
Sent: Tuesday, July 06, 1999 5:51 AM 
* To: Jacobi, Eli 

Cc: Wolfgor, Irit; Zimerman, Heny; Rimon, asaf; Neystadt, John; Erev, Art; Ron, Tamir 
Subject: Notification protocol patent 

Hi Eli, 

This is a preliminary version of the answers to the patents' questionnaire regarding the notification protocol. 

Please let me know if the answers are clear, if more information is needed, etc. I've tried to keep it as general as possible and not 

get into details. 

I'm forwarding this to some other people who are and/or were involved in the process of defining the protocol. 
Please send me comments and corrections as soon as possible, so that I can send Eli an updated version by Sunday. 

Thanks, 

«Notification protocol patent.doc» 


PREPARATORY QUESTIONS TO THE INVENTOR(S) 


The INVENTORS are defined as the individuals that provided a SOLUTION 
TO A SPECIFIC PROBLEM. It is preferable that the leading inventor will 

ANSWER THE QUESTIONS. 

[l] An invention is a solution to a problem. Describe the problem. 
Send notification requests that contain some information that may 
interest the subscriber to a notification service that will decide if. 
when and how to notify the subscriber of this information. 
in the context of voice mail and unified messaging system this 
information in the request usually describes changes a subscriber's 
mailbox status. 

Various clients can send notification requests- email servers, voice 
mail server and other applications. 

[2] describe briefly the invention. the explanations can be given 

on the whiteboard or assisted by pre-prepared schemes. 
a protocol between the clients and the notification service. the 
protocol enables the clients to describe the event they wish to report 
and defines the interaction between these clients and the notification 

SERVICE. 

The protocol is is text-based, and is implemented over the HTTP 
protocol. 

The protocol is extendible and can be used to send notification 
requests describing various types of information - a new message in a 
subscriber mailbox. subscriber mailbox is full. system shut down alert 
or even changes in the stock market. etc. 

[3] What is the impact of the invention on the project/ product! 
technology. 

Can you define the invention as VITAL [ ] IMPORTANT [ ] HELPFUL [ ] 7 
Vital. 

The protocol is the core technology by which various information 
sources send notification events to a centrailized notification service 
that implements a unified processing logic to these requests. 

[4] Was the invention practiced before in Comverse? Elsewhere? Have 
you 

seen this solution in writing in the professional media? in a 

PATENT? 

A SIMILAR SOLUTION? 

NO. 

The closest thing I know of is a feature in the IMAPfc protocol that 
enables the email server to notify the client of changes in the mailbox. 
There are several major differences between this IMAPl. feature and 
the notification protocol: 


• IMAPfc IS A PROTOCOL USED BY EMAIL CLIENTS TO REVIEW THEIR MAILBOX ON 
THE EMAIL SERVER AND IS CAPABLE OF NOTIFYING OF NEW MESSAGES ONLY. 
The notification protocol is NOT LIMITED TO RECEIVING INFORMATION 

from email servers. and is much more general in its capability to 
describe events from all sorts. 

* imaph requires keeping an open session between the client and the 
server. the notification protocol does not require that. a session is 
established only when there's something to report. 

[5] Have you (or anyone else) seen this solution practiced in a product? 
A similar solution? A product by a competitor? 

NO 

[6] Do you have regular access to trade magazines, technical articles? 

Are you visiting trade shows, or is information (related to your 
field of 

Interest) leaked to you from such shows? 
We have some access to the relevant technical information. 
The existahce and partial specification of the protocol are known to 
some companies with which comverse is discussing possible cooperation 
related to the matter. All companies have signed MP As with Comverse. 
and the informationwas marked "confidential". 

[7] Are you doing patent searches on new technologies practiced by 

YOU? 

If yes, have you found any patents relevant to the invention? 

No 

THE PRESENTATION OF EACH INVENTION WILL TAKE NO MORE 
THEN 15 MINUTES, FOLLOWED BY A DISCUSSION AND FOLLOW-UP 
QUESTIONS. 
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-1. Purpose 

The purpose of this document is to define the notification protocol and is intended" to W 
used both by CNS employees and by 3* parties that develop applications that needs to be 
able to send notification requests. 

1.1 Applicable Documents 

[1] RFC 2616 - HTTP/1.1 (http://irifo.wtemet.isi.edu^ 

2. Introduction 

Each client of the notification service will have to use this protocol in order to send 
notification requests to the notification service. The protocol is based on HTTP as its 
transport protocol. 

The notification, protocol defines the requests that the client can send to the notification ■ 
service and what information items are mandatory or optional in each request. It also 
deaenber the behavior of the client and the notification service regarding error handling, 

* retries » etc. 5 

Upon receiving a request, the notification service parses it and processes the request After 
processing the request the notification service MAY send a notification message to one or 
more .subscribers. 

3. Terminology and Acronyms 

NSrv - Notification Service 

HTTP - HyperText Transfer Protocol (relates to version 1.1) 
Client •> An application that sends notification requests 

3.1 Requirements phrasing 

The terminology in this document uses the standard keywords usually used ia RFC 

^ C mnTxT^ S J^5L5J° T ' Rfi Q ulRED » SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY and OPTIONAL) as described in RFC 21 19, 

An implementation of this protocol is not complaint if it fails to satisfy one or more of the 
MUST or REQUIRED requirements. An implementation is "unconditionally compliant" if 
it satisfies all the MUST, REQUIRED and SHOULD requirements. An implementation is 
conditionally compliant" if it satisfies all MUST requirements, but fails to satisfy at least 
one SHOULD requirement. 

4. Notification HTTP Protocol Specification 
4.1 HTTP Protocol version 

The Client SHOULD use the HTTP protocol version 1.1 in order to be able to maintain a 
persistent connection with the HTTP server. Using persistent connections allows the client 
to work more efficiently and use a single TCP connection for pipelining requests (sending 
several requests asynchronously. 
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4.2 Client Application Requirements 


4.2.1 Sending requests 

^ < ™l, comman<i ' 3 *"* wiU be suppled by the Notification HTTP Protocol are 'GET' 
and POST . 

4.2.2 HTTP port 

The port to be used between the client and the notification service is fixed and would 
usually not be the standard port used for HTTP communications. 

Denote this port by <NSrv Port> 

4.2.3 The notification service URL 

The URL the client sends requests to MUST be agreed upon between the client and the 
notification service and is part of the configuration of the service (e.g. if NSrv Port = 8080 
then the URL is: httpr/Znotifi^tionJoflmY^ft comiSOgQ/nntify ,^^ 

Denote this URL by <NSrv URL>. 

4.2.4 Notification request format 

A notification request MUST comply with the general format of a URI (Universal 
Resource Identifies) as defined in RFC 2616. It is composed from the notification service 
and several attribute names and their values. The detailed description of attribute 
names and legal values is described in detail in section 7 below. 

Assuming there are 3 attributes (al, a2, a3) and 3 values (vl, v2, v3), the format of the 
request that the client would send is: 

<NSrv URL>?fl=vl&f2=v2&f3*v3. 

Attribute values MUST conform to the standard encoding of HTTP commands - e i a 
blank should be ohanged to a V sign, etc. 

4.2.5 Synchronization and Avoiding race conditions 

The order of processing notification requests for a certain subscriber is very important 
Otherwise, the notification service may send the notification messages in the wrong order 
and may give the subscriber the wrong information regarding his mailbox status. 
The following describe the client's behavior in order to avoid these situations. 

4.2.5.1 Sending order 

The client MUST always send notification requests in the same order as the events that 
triggered them. 

4.2.5.2 Synchronous sending 

In case the client wishes to send several notification requests for the same subscriber in a 
short period of time, the client SHOULD wait for the notification service to respond by an 
Ack after sending each request before sending the next request for the same subscriber 
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4.2.5,3 _ Asynchronous sending 

If the client does not comply with 4.2.5.2 above, there MAY be cases' where" the ~~ 
notification service would send notification messages in the wrong order. In order to 
minimize the damage, the client MUST make sure that all the attributes regarding the 
mailbox status (see below) contain the most up-to-date data. 

For example, if a subscriber had no new messages in his mailbox, and he had just got two 
new messages and the email server (i.e. the client) wishes to send two separate notification 
requests. The client MUST indicate in both requests that the subscriber has two new 
messages (rather than the first request would indicate one new message, and the second 
would indicate two) 

4.2.6 Retries 

The client MAY perform retries when a server error occurred or when the notification 
service is temporarily unavailable (See 5.1 - Status codes). The client SHOULD determine 
the number of times it tries to re-send the request. 

When re-sending a request, the client MUST update the information in the request in order 
to ensure it contains the up-to-date information. 

4.2.7 Mailbox Full on/off 

A notification client SHOULD send notification requests when a subscriber's mailbox is 
full (i.e MailboxCapacity > MailboxCapacityThreshold). 

If a client application implements the sending of notification requests when the 
subscriber's mailbox is full, it MUST also send a notification request when the capacity of 
the mailbox has changed and is not considered to be full any more (i.e. MailboxCapacity 
<= MailboxCapacityThreshold) 

See paragraph 7.3 for the appropriate request attributes. 

5. Notification service requirements 
5.1 Status codes 

Status codes are sent from the HTTP server or from notification service to the client as a 
response for each request. 

The st atus c odes returned by the notification service comply with the status codes defined 
in the HTTP/1. 1 protocol (RFC 2616, section 10). 

When applicable, the notification service will use standard status codes. The notification 
service MAY use proprietary status codes, as long as they comply with the standard 
classification of status codes according to their numbering convention (see below). 

5.1.1.1 Informational (1xx) status codes 

The notification service will not send, at this stage, any informational status codes and the 
client MAY ignore all informational status codes sent by the HTTP server and/or by future 
versions of the notification service, 

Informational status code MAY be used in future versions to notify the client whether the 

notification request resulted in sending a notification message or not. 
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5.1,1,2 Successful (2xx) status codes 


l^f^f? 88rVer **F ST S6nd a " M0 0K " Coiie it had en sured that the 
SSL? Pr ° CeSSCd Wlth ° Ut ^ ° r ^ * *» ^ 

The notification service MAY use other (including proprietary) successful status codes 
After receiving a successful status code, the client MUST WJeriff retries 

5.1.1.3 Redirection (3xx) status codes 

N.A. 

5.1.1.4 Client error (4xx) status codes 

l^Sft*? S6rV ! f MUST „ send a cHea£ error status code when it finds out that the 
request fonnat or content are illegal - e.g, illegal attribute name, unknown subscriber id! 

The notification service will usually use the "400 Bad Request" status code but MAY also 
use other (including proprietary) client error status codes 

tw < ^!™.! rr °' 8tatus t codc « when using the "404 Not Found" status code, indicates 
that there s either a bug or a configuration error in the system, The client MUST NOT 
perform retries upon receiving one of these status codes as a reply. 

5.1.1 .4.1 The "404 Not Found" status code 

The notification service MUST NOT return a "404 Not Found" status code The HTTP 
server will return this status code when it cannot find the URI used by the client to 
describe the request. 

3S»£ SL ft ?*S at thCr0 ' S T "* y ° f MUnB error is Pwiuuicnt * not, the client 
S>rlOULD treat this status code like a server error status code (see 5.1.1.5 below). 

5.1.1.5 Server error (5xx) status codes 

The notification service MUST return a server error status code when it fails to process the 
request due to some internal error. The notification service will usually use the "500 
OTor^S^de^" ****** C ° de ' ^ ^ 8150 0th6f (kcludin S Proprietary) server 

Upon receiving any server error status code the client SHOULD perform retries if one of 
these status codes is sent as a reply (see 4.2.6). 

6. Notification Events 

Bach notification request is a consoquencc of an event. The supported events are: 

1) A new message has arrived for a subscriber, 

2) A subscriber read a message. 

3) A subscriber deleted a message. 

4) The server purged a message. 

5) The subscriber's mailbox is full. 

DaTe'soS^ Comverse Proprietary information 
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^_ _ _ ... 6 ) Update event - This event will be used if a subscriber's mailbox status has changed 

but the specific reason is unknown,-** when a notification-client-wishes to refresh the 
mailbox status, 

7) The subscriber has logged into his mailbox. 

7. Notification requests' Attributes 

A notification request is composed from several attributes and their values. Some 
attributes MUST or MAY appear only when other attributes have specific values (see 
below). 

The notification service MUST generate a client error status (See 5, 1,1.4 above) if a 
mandatory attribute is missing. 

The notification service will ignore redundant attributes. 

7.1 Common attributes 

The following table describes attributes that may always appear. 


Field Name 

Status 1 

Legal values 

NotificationProtocolVersion 

I 

Version 2 

ApplicationName 



ApplicationVersion 


Version 

ServerName 


String 

MailboxName 


String 

EmailAddress 

0 

Email 

Subscriberld 

0 

Integer >=0 

Eventld 

0 

Integer >=0 

TotalNumOfMsgs 

1 

Integer >*=0 

TotalNumOfNewMsgs 

1 

Integer >**0 

TotalNumOfNewUrgentMsgs 

1 

Integer >=0 

EventType 

1 

One of the following strings: 



1. NewMsg 



2. ReadMsg 



3. DeleteMsg 



4. PwgeMsg 



5. MailboxFull 


1 U'- Mandatory, '0' -Optional 

1 Version format is a sequence cf four integers separated by dots (e.g. 1.0.0.0), 
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7.2 


6. Update- 

7. Login 


tS* 1 SubsoriberlD attribute is missing, the notification service would use the 
ServerName and MadboxName attributes to get the subscriber's ID. It is possible that 
more than one subscriber uses the same mailbox. 

NewMsg attributes 

Hie following table describes attributes that may only appear if EventType is 'NewMsg'. 


Field Name 

Status 

Legal values 

MessageTVpe 

1 

One of the followinc strings • 



1. Email 



2. Voice 



3. Fax 



4, VoiceFax 

Memgeld 

0 

IMAP4 message ID 



(8 byte string) 

FirstNew 

0 

Yes/No -default is No 

Confidential 

0 

Yes/No - default is No 

ReplyRequested 

0 

Yes/No - default is No 

Urgent 

0 

Yes/No - default is No 

From 

1 

String 

To 

1 

String 

cc 

0 

String 

Subject 

1 

String 

Time 

1 

MM/DD/YYYY HH;MM:SS 

Body 

0 

String 

NumOfAttachtfients 

✓ 

0 

Integer >=0 

AttachmentNames 

0 

String 


7.3 MailboxFuIl attributes 

The following table describes attributes that may only appear if EventType is 'MalboxFuIl' 


Field Name 


MailboxCapacity 
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Status Legal values 


0 <= Integer <= 100 
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unity 


MailboxCapadtyThreshold 
Msi!boxFu!!Statu$ 


0 
l 


0 <- Integer <=_1 00 

St™* 


If MaliboxCapacity > MailboxCapacityThreshald --> Mailbox is full 

If MailboxCapacity MailboxCapacityThreshold ~> Mailbox was full, but it is not 
full any more (capacity is now below threshold) 
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